| PCIe to CAN 调试过程记录(好大的坑，还好爬出来了) | 您所在的位置：网站首页 › can fpga › PCIe to CAN 调试过程记录(好大的坑，还好爬出来了) |
PCIe to CAN 调试过程记录(好大的坑，还好爬出来了)
|
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接：https://blog.csdn.net/qq_46621272/article/details/118248322? 采用 FPGA + SJA1000 实现 PCIe to CAN 调试过程记录 FPGA为什么选 XC7A200TFFG1156-2，PCIE to CAN 是后加的功能，原产品采用了 XC7A200TFFG1156-2 做图像处理。后加 PCIE to CAN 就在这个基础上做的。 CAN 为什么选 SJA1000 ，其实从硬件设计上看，XILINX 有个 AXI CAN 的 IP , Linux 也有驱动(没调试验证过)，没授权也就没采纳该方案。查看市场上 PCIE CAN 卡多数都是用 PCIE 桥片 + SJA1000 芯片 实现，查看当前 Linux CAN 驱动芯片列表 SJA1000 芯片占一大项，芯片好买，参考代码多，为减少软件驱动编写开发的难度决定采用该芯片。 CPU 华为海思 Hi3531D 操作系统 Linux 3.18.20 Xilinx FPGA 芯片 XC7A200TFFG1156-2 FPGA 开发工具 Vivado 2017.4 有技术问题可以联系 [email protected] PCIE CAN 调试记录故障1： 硬件电路设计有问题， Xilinx Artix7 FPGA 只有一个 PCIE 且只能在 GTP bank 216 ,电路设计使用的是 GTP bank 116. 导致 FPGA 编译布线失败。见下面错误的原理图。 这是个有两处错误的图，一、 PCIE 管脚分配不对，二、PCIE 差分时钟没串接电容。是两个严重的低级错误。(羞愧、郁闷中) 这是个不该发生的低级错误，在FPGA设计中，特别是管脚定义，一定要仔细核实，最好先做部分设计来验证管脚的约束是否正确。否则做完PCB焊好原件后调试再发现问题就麻烦大了。 查看PCB版图，看能不能飞线补救，上帝保佑，FPGA GTP bank216 的管脚设计时留做扩展用，引到一个插座上，海思 CPU 部分采用购买的成品核心板，用 0.8mm 接插件，将原来的 PCIE 线在CPU核心板插座根部切断后重新从插座上飞线难度不太大。 考虑FPGA GTP216、116 时钟部分是可以互换共享的，就少飞了时钟线，只飞了 2 对 TX/RX 差分线(在飞线上串接了2对电容)。 采用新的 GTP 管脚约束。重新编译 FPGA 代码，顺利完成。经过仔细测试，Linux 用 # lspci 找不到 FPGA PCIE 设备，最后发现 AXI_CLK，没产生，怀疑 PCIE 时钟有问题。经过仔细的反复的排查测试，怀疑是 CPU PCIE_CLK 与 FPGA 的线路缺少一对交流耦合电容。 故障2： CPU PCIE_CLK 与 FPGA 的线路缺少一对交流耦合电容。(低级恶心的错误，怀疑 FPGA 代码、怀疑 CPU 软件初始化、怀疑PCB线路设计、怀疑飞线不可靠、怀疑一切、耗费2天，郁闷)解决办法，还是飞线，将原时钟线切除，飞一对串接了2对电容差分线。用新的 GTP 管脚约束。再次编译 FPGA 代码、测试。 AXI_CLK 正常。进 Linux 用 # lspci 任然找不到 FPGA PCIE 设备，故障依旧。 再次开启怀疑模式，怀疑 FPGA 代码、怀疑 CPU 软件初始化、怀疑PCB线路设计、怀疑飞线不可靠、怀疑一切。开始检查飞线并换用可靠的屏蔽的 100ohm 双绞线(从 USB 3.0 电缆中拆的)、啃 PCIE 协议、看 linux 内核代码、查看 CPU 文档、拟定测试方法步骤。 PCIE 能够测量出来的故障表现 PICE时钟，在加电时时钟没有，进入 Uboot PCIE时钟任然没有，引导Linux 内核的过程中，PCIE 100MHz时钟出现，但是时钟出现、停止、出现、停止、出现才稳定正常。PCIE时钟是海思CPU输出的，是需要初始化相关寄存器才能正常输出的。 FPGA PCIE IP 内部的 AXI_RSTN 始终为低。(FPGA PCIE 模块没有成功复位) CPU PCIE 没有专门的 RESET 信号。 分析: CPU启动后引导Linux内核启动，初始化PCIE寄存器、FLR（Function Level Reset）、复位时造成PCIE时钟的间歇出现。这不是大毛病，最多算是个小BUG，关键是CPU 执行FLR时，FPGA 不知道，FPGA PCIE没有有效的RESET信号去触发。做个实验:FPGA引出个脚，接上拉电阻，接个按键开关，用来手动复位FPGA PCIE。系统上电在引导内核时，眼睛盯着示波器，当PCIE时钟稳定时手动复位一下FPGA PCIE，反复做了几十次，大概1/5 的概率，Linux起来后成功找到XILINX FPGA PCIE设备。 通过实验，基本锁定故障原因。 解决方法: 用FPGA监测 PCIE 时钟是否出现间歇，出现间歇就产生一个FPGA PCIE的RESET信号。编写新的逻辑，烧入FPGA测试，修改下参数再试，反复测试。最后经过千次的断电、硬复位、软复位重启均能稳定的找到XILINX FPGA PCIE 设备。 至此PCIE接口硬件故障解决。 总结: 两个低级的错误。PCIE 管脚分配不对。PCIE 差分时钟没串接电容。是两个严重的低级错误。(羞愧、郁闷中) 这两个错误严重影响了后面故障的判断，每次的怀疑都绕不开飞线对不对，影不影响信号质量。后面PCIE复位问题，在排查飞线问题后其实只要细心测试总结总能找到问题的关键。连接：采用 FPGA 实现 ＜PCIe to CAN＞ 网卡的设计 https://blog.csdn.net/qq_46621272/article/details/118242161? |
【本文地址】